home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 3153 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.4 KB
  1. Path: tudelft.nl!news
  2. From: Ejo Schrama <schrama@geo.tudelft.nl>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Why are 32 bit better than 16 bit pgms?
  5. Date: 22 Jan 1996 12:13:55 GMT
  6. Organization: TU Delft, Faculty of Geodetic Engineering
  7. Message-ID: <4dvv23$mcl@mo6.rc.tudelft.nl>
  8. References: <4dniuk$lms@dragon.solect.com> <30FBFFE6.1FEB@netcom.com> <4do422$jj1@vixen.cso.uiuc.edu>
  9. NNTP-Posting-Host: dutgs7.geo.tudelft.nl
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.12 (X11; I; HP-UX A.09.05 9000/735)
  14. X-URL: news:4do422$jj1@vixen.cso.uiuc.edu
  15.  
  16. sjmccaug@prairienet.org (Scott J. McCaughrin) wrote:
  17. >
  18. >In a previous article, gallantm@kanservu.ca (Matt Gallant) says:
  19. >
  20. >>In article <30FBFFE6.1FEB@netcom.com>, vain@netcom.com says...
  21. >>>
  22. >>>I have a simple questions:
  23. >>>
  24. >>>   What's are 32 bit pgms better than 16 bit programs?
  25. >>>
  26. >>>   Thanks!
  27. >>
  28. >>The answer to this question can be a matter of opinion.  The common answers 
  29. >>given are:
  30. >>
  31. >>1. For developers, programming becomes easier because you no longer have to 
  32. >>worry about memory segmentation.  Because of this, data structures and blocks 
  33. >>are no longer limited to 64K.  No more segment:offset addressing.  Your 
  34. >>program can "pretend" that memory is a "flat" range, and just use 32-bit pointers 
  35. >>ranging from byte 0 through 4GB.  (Of course, not all of this memory area is valid 
  36. >>to the process without making the proper memory allocations)
  37. >>
  38. >
  39. > But with "huge" memory model permits the 64K limit to be exceeded in the
  40. > real-mode model, and not everyone considers segmented memory a constraint.
  41.  
  42. Just take a look at the stacksize for the huge memory mode. It is still 64K
  43. thereby causing a limitation. A 32 C++ compiler like DJGPP doesn't have
  44. this limitation.
  45.  
  46. >
  47. >>2. 32-bit programs are pre-emptively multitasked.  A 32-bit application can no 
  48. >>longer hog the process by not yielding on a timely basis.  (There is one snag to 
  49. >>this scheme if you're running on Windows 95, and if you develop for Windows 95 
  50. >>you are sure to hear about it.  This "snag" is refered to as the Win16Lock or 
  51. >>Win16Mutex.)
  52. >
  53. > This is more a feature of Win95 than the memory model -- besides, there are
  54. > advantages to non-preemptive multitasking. Also, consider CDOS and Concurrent
  55. > PC-DOS.
  56. >
  57.  
  58. IMHO multitasking and 16/32 bit applications are a different thing (in general
  59. at least). There is no reason why one couldn't develop a multitasking 16 bit 
  60. os. RSX11M on the PDP11-70 was 16 bits and multitasking but is completely outdated
  61. of course.
  62.  
  63. >>
  64. >>3. 32-bit programs are (to a large extent) portable.  If written correctly, one set 
  65. >>of source files can be compiled and run on Windows 95 and Windows NT, as well 
  66. >>as being compiled for other non-Intel x86 platforms (i.e.  Alpha processors).
  67. >
  68. > I believe Win95 supports 16-bit code for backward compatibility as well.
  69. >
  70.  
  71. Also this is in general unrelated to the 16/32 bits discussion. Sorry. 
  72.  
  73. >>
  74. >>4. Also, consider that as new APIs are developed (by Microsoft and 3rd parties) 
  75. >>that they will probably only be ported to the Win32 platforms.  For example, I 
  76. >>was just reading an Microsoft Systems Journal article about their new Speech API. 
  77. >> I'm not sure that it's necessarily 32-bit only, but obviously, something as 
  78. >>processing-intensive as speech synthesis and speech recognition will benefit from 
  79. >>32-bits.
  80. >>
  81. >>5. Last, but definitely not least, 32-bit programs are allowed to have multiple 
  82. >>threads of execution.  This allows you to easily create and execute routines "in the 
  83. >>background" just by creating a new thread.  You no longer have to set up your 
  84. >>different tasks to be done and come up with ways of switching between them 
  85. >>yourself, just create a new thread, and Win32 platforms will schedule your 
  86. >>background tasks themselves.
  87. >>
  88. > So what? This is the standard for OS/2 as well, which is designed to run in
  89. > '286 protected-mode (only 24-bit addressing, not 32-bit). Again, this is more
  90. > a feature of the operating system than the memory model.
  91. >
  92. > -- Scott McC.
  93. >
  94.  
  95. -- 
  96. -------------------------------------------------------------------
  97.  Ernst J.O. (Ejo) Schrama, Faculty of Geodetic Engineering, 
  98.  Thijsseweg 11, 2629 JA Delft, Netherlands. schrama@geo.tudelft.nl
  99.  Tel: (31) 15 2784975, Fax: (31) 15 2783711, Page: 065-9762479 
  100.  homepage: http://www.geo.tudelft.nl/~fmr/people/schrama.html 
  101.  daugther: ftp://www.geo.tudelft.nl/pub/ejo/michelle
  102. -------------------------------------------------------------------
  103.  
  104.